How Do You Balance Feature Development and Technical Debt?
Let's discuss how to balance feature development and technical debt.
We'll cover the following
Giving your team a good environment to foster engineering excellence is one key feature that boosts employee retention. Technical debt is very real, and you have to make sure you give your engineers a clean codebase to work with. However, this also differs from company to company. A start-up might have a messier codebase and might be willing to pay the technical debt to achieve their short-term goals, whereas an established company might be more concerned with their long-term bottom-line since they would be out of their survival phase. How you approach technical debt has to be in line with the company’s overarching goals.
What the interviewer is looking for#
- How you prioritize technical debt, taking into consideration the goals of your company.
- How you perceive technical debt and its implications.
- Whether or not you are empathetic toward how it affects your team.
What a good answer looks like#
“As an engineering manager, I have realized that it’s very important for me to keep an eye on engineering tasks and make sure they’re factored into plans and timelines that product managers may set.
On one of the teams I worked in, we did three-week sprints. Before each sprint, we would have immersive planning sessions and a whole backlog of business and functional requirements that came from the product manager. In addition to all that, we also maintained a separate backlog of engineering items. Product managers are usually not aware of these engineering items, but I see them as an important part of the backlog that needs to be addressed and prioritized. We brought these items into every sprint plan, and it was a good mix of things depending on the requirements of the sprint. In some sprints, after negotiation, technical debt was given less priority simply because there was a committed deliverable to the client. In other sprints, we had more margin.
As an engineering manager, it was my responsibility to make sure everyone was aligned and convince nonengineering members of the importance of the engineering items. I couldn’t expect them to be aware of things like simple refactoring and how it could impact future functional backlog delivery. It was my job to communicate this to them. Therefore, it was my responsibility to advocate for these items wherever needed and give them their due importance when each sprint was planned.”
Red flags in your answer#
Some of the things that shouldn’t part of a good answer are:
- Not giving technical debt importance during the planning phase.
- Leaving technical debt to be dealt with by the engineers alone.
- Getting frustrated at management for not giving you time to address technical debt.
- Not recognizing your responsibility to communicate its importance to them.
How Do You Plan a Project That Involves Multiple Teams?
How Do You Discuss Engineering Limitations with Customers?